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Expected Value Methods and Systems for Paying and Qualifying 

Cross References 

This specification makes reference to US Patent 5,269,521 concerning the expected value 
payment method. This specification was preceded by disclosure document 451365 
(2/10/99). It was also preceded by provisional applications 60/142,592 (7/7/99) and 
60/149,654 (8/1 8/99). It was also preceded by disclosure document 468,799 (1/3 1/00). 

Background — Field of the Invention 

This invention relates to database systems for paying people for their attention. 

Background — The Prior Art 

Many people have stated that attention is a scarce resource and, therefore, people need to 
be paid to view ads. Many systems exist, such as one implemented Cybergold.com (US 
Patent 5,794,210), for paying people for viewing ads. But these systems do not solve the 
fundamental problem of advertising, which is that advertisers spend most of their money 
to reach unqualified recipients. Most of these systems are based on the demographics of 
audiences or on so-called "profiles" to determine payments. Neither approach is 
adequate, which means that these systems, like all current ad media, are inefficient. 
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The invention solves the problem of wasted advertising by enabling advertisers to pay 
only for messages delivered to recipients who meet qualifications specified by the 
advertisers. The key to the system is efficient verification and payment, which is 
accomplished in a novel way, disclosed in this specification. The invention makes 
possible a new form of advertising — Verification-Based, Pay- for- Attention Advertising. 

Perhaps the most significant application of the invention is one where a seller agrees to 
pay a prospect if the prospect proves his intent to buy the product being advertised. By 
paying only those who are ready to buy the seller's product, the seller can pay significant 
amounts of money to a prospect because the probability of a sale is significant. Thus, this 
particular application of the invention solves the search problem of advertising, which is 
how to find and get the attention of people who are ready to buy the advertiser's product. 

Object of the Invention 

The object of the invention is to enable advertisers to qualify prospects and pay only 
qualifying prospects for receiving advertising. 
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Summary of the Invention 



The invention is method and system for enabling advertisers to pay only qualified people 
for receiving messages. The system presents online forms and a database that enable 
advertisers to specify qualifications, post payment offers, and transact payments. It also 
presents forms, or their voice equivalents, that enable recipients to find and accept the 
payment offers. The system can also enable recipients to be exposed to the ad messages. 

The system utilizes the expected value payment method (EVPM), described in US patent 
5,269,521. In this method, the recipient is paid an expected value (EV) payment. The 
recipient collects an actual payoff only upon winning an EV payment bet and upon 
passing an inspection process to verify her qualifications. A losing recipient is not owed a 
payoff and does not have her qualifications inspected. 

In other words, a recipient's qualifications are verified through random audit where she is 
selected only if she wins an EV payment bet. Thus, the system executes EV payment bets 
and incorporates an inspection process to verify the qualifications of recipients who win 
the bets, and authorize payment to qualified winners. 
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Preface: About the Invention and this Specification 



A General System for Paying for Attention 

In its most general form, the invention is an online database system for enabling a person 
or company to pay for the attention of people who meet specified qualifications. 

Paying people for their attention can be useful in a variety of situations but only if the 
payer can select the payees based on desired criteria. As some examples, a city might 
want to pay teenage girls to read literature about birth control, a company might want to 
pay computer scientists to read a recruitment offer, and the maker of an asthma medicine 
might want to pay asthma sufferers to read about the medicine. 

The invention enables an advertiser to target his audience precisely, according to 
verifiable criteria, and pay only that audience for its attention. 

Expected Value Payment and Post-Qualification Are the Keys to the System 

The problem with paying someone for her attention is that it normally costs too much to 
verify the person ? s qualifications in advance because the amounts paid are small. For 
example, if a city wants to pay 13 -year-olds $2 to read an article about birth control, it is 
too costly to check in advance the age of every person who might accept the offer. 

A general solution to this problem is to pay people expected amounts of money through 
the EVPM and to only inspect the qualifications of the winners. 
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In other words, recipients are paid for their attention with electronic lottery tickets that 
have a specified EV, with a 1/X chance of paying off. After recipients have paid 
attention, the results of the tickets are revealed and only the winners (1/X of all the 
people who have paid attention) are asked to prove that they match the qualifications. 

This kind of verification is probabilistic /wsf-qualification. The winners who do not 
match the qualifications are paid nothing. The winners who match the qualifications are 
paid X times the EV amount. 

For instance, assume Denver offers to pay $2 to all 13-year-olds who live in Denver and 
read an article on birth control at the city's website. Assume a set of people then reads the 
article on the site, which registers the identity of each person who wants to accept the 
offer. A fraction of that set of people, say 1/500, is chosen randomly to be the set of 
winners. Each winner is paid 500 x $2 ($1000) if she proves that she is a 13-year-old who 
lives in Denver. The city does not have to verify, in advance, that the readers are 13- 
years-old or that they live in Denver, and the city does not have to pay everyone who 
reads that article, just the winners of the EVPM bets who are also 13 year-olds. 

Thus, the EVPM is used both as an efficient payment method and an audit selection 
method — the people who are inspected and paid are probabilistically chosen. A surprising 
double-efficiency results: efficient payment and efficient qualification. 

And so, we have an efficient, general method for paying only for the attention of people 
who match specified criteria. 

(In fact, the general method is a special case of an even more general method called The 
Expected Value Inspection Method, described in disclosure document 468,799.) 
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Naming the Offers: EVQ Offers 

The invention is a system for enabling advertisers to make Expected Value Qualification 
(EVQ) offers to recipients. In the context of this specification, we will also refer to EVQ 
offers simply as payment offers or offers. 

An EVQ offer is one where the advertisers agrees to pay the recipient an EV amount of 
money if the recipient meets the qualifications/conditions set out in the offer. 

In other words, what this means is that the advertiser agrees to pay the recipient the 
payoff of an EV payment bet if the recipient wins the bet AND meets the 
qualifications/conditions set out in the offer 

This Specification Describes the Core Processes of the Invention 

This specification describes a set of core processes that enable advertisers to pay for the 
attention of recipients who meet specified qualifications. In brief, these processes do the 
following: 

• enable advertisers to make and post EVQ payment offers 

• enable recipients to find and accept those offers 

• enable advertisers to verify the qualifications of the recipients 

• enable advertisers to pay recipients who qualify. 

By core processes we mean the sequences of steps that the system executes to achieve its 
minimum purpose to enable advertisers to offer to pay qualified recipients using the EV 
payment method. 



6 



Many features can be added to the set of core processes in order to adapt the invention to 
particular applications. By analogy we might think of the set of core processes as an 
elemental design, like the design of a vehicle with four wheels. It can be adapted in a 
great variety of ways: a car, a truck, a bus, a tractor, and so forth. Likewise, the core 
invention disclosed here can be adapted in a wide variety of ways. 

In future continuing applications we will delve into more specific embodiments of the 
invention. In this specification, we will illustrate with two embodiments. We do not mean 
to limit the invention in any way. Quite the contrary, the invention is so general, that it 
seems best to describe its basic form here and then disclose more specific 
implementations in future applications. 

The Core Processes Can Be Implemented for a Variety of Media 

Since there is not just one kind of "attention 11 the invention can enable advertisers to pay 
for different kinds of attention and pay recipients for receiving different kinds of 
messages. We will describe the core processes first without having any specific type of 
message in mind. 

As reduced to practice, the invention will need to have a frontend and other features that 
are suitable to the kind of message medium being used: webpage, one-way video, 
interactive video, phone call, or email, (the invention can even be adapted to pay 
recipients for participating in face-to- face meetings.) 

We will illustrate the invention with a webpage application and a phone call application. 
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Pay-for-Placement Directory Implementation 

Payment offers can be stored in a "non-competitive" database whose purpose is simply to 
enable recipients to find and accept the offers. Another kind of system is a competitive, 
auction/directory — a pay for placement system — in which offers are presented according 
search term and payment offered to the recipient. A pay-for-placement directory will 
likely be a very useful form of the invention because it enables market forces to 
determine the priority by which pay-for-attention offers are seen. 

Naming the Invention: System for Paying and Qualifying (SPQ). 

The invention is a set of methods (processes) that, in combination, direct a computer 
database system to perform useful functions. The full name of the invention is Expected 
Value Methods and Systems for Paying and Qualifying. We will abbreviate it to System 
for Paying and Qualifying (SPQ). 

Referring to the Invention Anthropomorphically 

For brevity we often refer to the SPQ anthropomorphically and assume that the reader 
realizes that when we say, n SPQ does so-and-so", we mean, "The system for paying and 
qualifying includes functions for doing so-and-so." 
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Usage of the Terms Process, Procedure and Program 

The invention is a computer database system that executes a set of processes to 
accomplish certain tasks. In this specification, we use the terms process, procedure and 
program synonymously to refer to a set of steps that the computer executes. 

Usage of the Terms Advertiser, Recipient and Qualified Recipient 

When we use the term advertiser we mean a person or organization that wants to pay for 
a qualified recipient's attention to a message. The advertiser sets the qualifications. 

Accordingly, when we say a recipient, we mean someone who can receive the 
advertiser's message. When we say qualified recipient we mean someone who meets the 
advertiser's qualifications for payment. 

Defining and Naming Data Records 

In this specification we define and name several kinds of data records (which may also be 
called files or objects). In giving these definitions, we are not trying to say exactly how 
the system would store information. Our goal is just to explain the kinds of information 
that SPQ would store. Those skilled in the art will easily see alternative ways to name 
and store this information. 
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"Data Field" May Refer to a Single Field or Multiple Fields 

For the sake of brevity, rather than say a "data field or fields" we will usually just say "a 
field" or "the field". When using the term "field" the point is to state that the system 
registers a particular, named piece of information or set of information. 

The information in the field might actually require multiple fields (e.g., a legal name field 
might be split into three fields: first name, last name, middle initial). Those skilled in the 
art will know where multiple fields are more appropriate than a single field for the 
information in question. 

Describing What Is Novel 

In this specification we strive to only describe what is novel. We omit details of processes 
and functions where the steps are obvious to those skilled in the art. 
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1.1 DEFINITIONS and GENERAL ELEMENTS for the CORE PROCESSES 



Here we give definitions used in describing the core processes. We add definitions as 
necessary throughout this specification. 

General Elements 

SPQ is an online database system that includes memory means, input/output means, 
calculation means, and search means. SPQ includes frontend interfaces for enabling users 
to enter data objects (e.g., "offers") and associated data. SPQ also includes frontend 
interfaces for enabling users to find and select data objects. The term frontend interface 
encompasses a wide variety of well-known mechanisms for entering and selecting data. 

EVQ Offers 

SPQ is a system for enabling advertisers to make EVQ offers to recipients. An EVQ offer 
is one where the advertisers agrees to pay the recipient an EV amount of money if the 
recipient meets the qualifications/conditions set out in the offer. In the context of this 
specification, we will also refer to EVQ offers as pay-for-attention offers, payment offers 
or simply offers. 
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Three Kinds of Users 



SPQ has three classes of users: advertisers, recipients and inspectors defined below. 
(Note: we omit system administrators because they are not involved with the novel 
features of the invention). 

Advertiser (also called Addy). User who makes a pay-for-attention offer (an EVQ offer) 
to qualified recipients. 

Recipient (also called Reece). User who finds and accepts EVQ offers from advertisers. 

Qualified Recipient (also called Q-Reece). User who is eligible to be paid according to 
the terms of an advertiser's EVQ offer. 

Recipient Agent. User who represents a recipient for the purpose of entering data for the 
recipient. For example, in certain implementations, a recipient might be represented by a 
telephone operator who enters ID and offer acceptance data into SPQ on behalf of a 
recipient. Note: we will consider a recipient agent to be the same as a recipient. 

Inspector (also called Vera). User who verifies that the terms of an offer are met or not. 
Three Key Data Sets 

SPQ makes use of three key data sets: offer data, offer request data and inspector report 
data — one for each kind of user. These are not the only data sets that SPQ uses, but they 
are the critical, minimal ones. 

Offer Data. This is the data an advertiser enters to create a payment offer. 
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Offer Request Data. This is the data a recipient enters to find and accept an offer. (Note: 
in many implementations, a recipient will only have "press a button" in order to find and 
accept an offer and will not have to enter a set of data. In other implementations, the 
recipient will have to enter a code, and in others, a set of search criteria.) 

Inspection Report Data. This is the data an inspector enters to state whether or not a 
recipient has met the conditions of an offer. 

Three Core Processes 

SPQ has three "core processes", one for each kind of user. These are not the only 
processes that SPQ can include for users but they are the minimal ones. Together these 
processes comprise the overall core process. 

• Advertiser (Create/Post Offer) Process. In this process, the advertiser submits the 
terms of her offer. 

• Recipient (Find/Accept Offer) Process. In this process, the recipient finds and 
accepts an offer, and SPQ processes the acceptance. 

• Inspector (Inspect/Verify Qualifications) Process. In this process, the inspector 
decides whether a winning recipient has met the conditions of an EVQ offer. 

SPQ will also include payment processes, which are integrated into the three core 
processes above. Payment processes vary depending upon the implementation, so we 
describe them separately for the sake of clarity. 
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1.2 ELEMENTS and STEPS for the ADVERTISER PROCESS 



Introduction to the Advertiser Process 

The advertiser process enables Addy to create and post an EVQ offer to recipients. There 
is no single process to be described since many variations are possible. Any overall 
advertiser process will include elements and steps for enabling the following actions: 

1 . Creating an advertiser account 

2. Entering an offer 

3. Making the offer accessible to recipients 

4. Modifying the offer or making it inaccessible to recipients 

5. Registering payment obligations of the advertiser. 

In this section, we describe these elements and steps, focusing on the data elements that 
are necessary for entering an offer, as these involve the novel aspects of the invention. 

1. Steps for Account Creation and Advertiser Authentication 

As part of the overall advertiser process, it is necessary to authenticate the advertiser. So, 
SPQ includes steps for creating an advertiser account and authenticating an advertiser. 
We do not elaborate because such elements and steps are well known. 
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2. The Offer Data, the Fundamental Data Set/Object of SPQ 

Since the advertiser process enables Addy to create and post an EVQ offer to recipients, 
it mainly consists of outputting an offer form to her and storing the data she fills into it. 
We will call this set of data the offer document, or the offer data or, simply, the offer. 

SPQ stores the offer data that is entered into the form and timestamps the entry. 

The data in the offer form serve three purposes: 

• They define the EVQ offer — that is, the contract offered by Addy to recipients. 

• They act as instructions that direct SPQ when the offer is accepted. 

• They enable the offer to be found by Addy and recipients. 

Thus, the offer form data are the fundamental data set (data object) of the system, which 
is natural, given that most of the actions of the system revolve around handling and 
transacting offers. 

The offer form is not necessarily a monolithic form in which all the offer data is entered 
at the same time. Offer form data can be entered through different forms, at different 
times — the sequence of entry and the presentation of forms will depend on the 
implementation. The concept of a single offer form is an abstraction. The point is to 
explain the data input fields that the system will present to advertisers — that is to say, the 
goal is to describe the types of data that the system inputs from an advertiser to create and 
store an offer that can be found and accepted by recipients. 

In this section we describe the key data fields that an offer form includes. Some of these 
fields are always required; others depend on the implementation. Fields can be added, 
since an offer can include many conditions. 



16 



Field 1: Name Used by the Advertiser for the Offer Document 

In order for an advertiser to find an offer that she has entered, it is useful to name that 
offer, just as naming any document is useful. Thus one field in an offer form is an offer 
name field enabling Addy to name the offer she enters so that she can find it. 

Field 2: Name Used by the System to Identify an Offer Document 

The system may also enable Addy to enter a separate name that is a system document 
name for identifying the offer. This kind of name may be useful in storing the offer in the 
system database and linking it to a recipient interface, as for example, associating the 
offer with a hyperlink. 

Addy may not have to enter a system document name. The system may automatically 
apply a system document name to the set of data comprising the offer. 

Whether a system document name is used or not depends on the implementation. 
Field 3: Data for Enabling Recipients to Find an Offer 

An offer is meant to be found and accepted by recipients. Thus, the advertiser process 
will include a step or steps by which Addy identifies the offer so that it can be associated 
with an input by the recipient — that is, so that a recipient who interfaces with the system 
can find and accept it. 

Finding and accepting may be the same action or they may be separate actions, 
depending on the implementation. For example, SPQ may enable Reece to simply press a 
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button to find and accept an offer. Reece does not even need to see the details of the 
offer. Alternatively, the system may enable Reece to find an offer and then press a 
separate button to signify that he accepts the offer. 

There are many well-known methods for enabling a recipient to find and accept an offer. 
The method that is used will depend on the frontend implementation. We will not delve 
into the great variety of specific ways that can be employed because there is no novelty 
involved, but we will briefly discuss three general methods and explain how they may or 
may not be implemented in an offer form. We describe these different possibilities for the 
sake of explaining the breadth of application of the system. 

A. If the offer is found through a "button" or the equivalent 

One way to enable Reece to find Addy ! s offer is for SPQ to be accessed through a button 
or link that, when selected, signifies that Reece has selected the offer. For example, a 
website for a health club might show the following hyperlink: Click this link if you live in 
Denver and want to get paid $1 for reading about our health club. Likewise, the system 
might have an interactive voice response frontend that identifies the offer when Reece 
presses a particular button. For example, Press "1 " if you live in Denver want to get paid 
$1 to talk with one of our associates about our health club. 

As another example, a health club might have special phone number that is connected to 
SPQ such that calling the number signifies that the recipient accepts an EVQ offer 
identified in the SPQ database by that number. 

In cases where SPQ enables Reece to find and accept an offer without entering search 
criteria into SPQ, but only through a "press-a-button" input, SPQ will require a step by 
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which Addy associates the offer with the "button" — i.e., associates the offer with the 
recipient input. 

B. If the offer is found through a unique name/code 

Another way that Reece can find an offer is through a name (code), which we will call a 
lookup name or lookup code because its purpose is to enable Reece to find the offer. 

The lookup name is entered into a search mechanism, such as a search form, that is part 
of SPQ's frontend for recipients. 

As an example of how such a code might be used, a print ad could have the following 
text, If you are about to join a health club, we'll pay you $1 to read about our club. Go to 
healthclub.com and enter "healthy" into the appropriate box. Or call 1-800-healthclub 
and enter "h-e-a-l-t-h-y " at the appropriate prompt. 

Thus, the offer form can include a field for entering a lookup code to be associated with 
the offer. Alternatively, the advertiser process can include a separate step in which Addy 
associates the offer with a lookup code. 

C. If the offer is found using search criteria 

Another way to enable Reece to find an offer is by entering search criteria such as 
keywords and other parameters that can be used to identify the offer. 

The offer form can include fields for entering data that identifies the offer. For example, 
the fields can enable Addy to enter search terms, or titles, or questions that can then be 
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matched by Reece. The offer form can enable the offer to be identified by multiple terms. 
For example, Addy might identify her offer by the keywords health, health club, gym, 
and exercise studio. And Reece might enter exercise club into the SPQ search engine. 
And SPQ could then use this phrase to identify Addy's offer, which would then be 
presented to Reece. Identifying data — search criteria — are not restricted to terms and 
phrases, of course. They can include a wide variety of parameter relevant to an offer. 

Special identifier fields may not necessary in the offer form because the offer conditions 
themselves (see below) can act as identifiers of the offer. For example, if an offer is made 
to Dentists who live in Denver, the SPQ search means may allow recipients to search for 
the term, dentist, and the city, Denver. 

Indeed, in implementations of SPQ that enable recipients to use a search form for finding 
offers, the offer description and conditions will probably be the favored parameters for 
identifying and searching the offers (this method is the favored one were online markets 
are concerned). 

We note that in certain implementations SPQ will be directory that contains different 
offers listed under the same search term. In this case, additional parameters will 
distinguish one offer from another. 

While we have nothing novel to add where the finding of offers is concerned, we 
emphasize that SPQ can enable advertisers to identify their offers by entering a variety of 
descriptive data, and we do not mean to limit the possibilities in any way. Virtually any 
type of database search means can be incorporated into SPQ for finding offers. 



20 



Field 4: Data for Accessing the Advertising 

In an EVQ offer Addy offers to pay Reece for his attention to her advertising. 

There are three different ways that SPQ can be implemented regarding how Reece is 
exposed to Addy's advertising: 

A. SPQ can play no role. 

B. SPQ can provide Reece with the data necessary to receive Addy's advertising. 

C. SPQ can store Addy's advertising and output it to Reece. 

(Note: in all cases, SPQ does register that Reece was exposed to Addy's advertising or, 
at least, that Reece accepted the offer.) 

A. If SPQ plays no role in exposing Reece to Addy's advertising then the offer form will 
not include a field for entering data that enables Reece to access Addy's advertising. 

SPQ can be implemented so that it takes no role in the advertising process. For example, 
Addy can offer to pay Reece for calling Addy. Addy can show Reece her phone number 
outside the SPQ system, say, in a print advertisement. Reece can call and then, after the 
call, Reece or Addy can report the call to SPQ. As another example, if Addy enables 
Reece to accept her offer on her website by pressing a button on the site, SPQ does not 
have to a play direct role in Reece seeing Addy's ad. SPQ can simply be notified by the 
website that Reece has accepted Addy's offer. As yet another example, SPQ Addy's 
advertising could show Reece a "proof-of-attention" code which Reece could enter into 
SPQ, signifying that Reece accepts the offer that corresponds to that code and that Reece 
has been exposed to the advertising. 
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B. If SPQ provides Reece with data to access Addy 's advertising then the offer firm will 
include a field for entering this data. 

If SPQ connects Reece to Addy's advertisement, then SPQ is also a kind of 
"switchboard" (with novel payment functionality). We use the term "connect" loosely 
because SPQ will not necessarily maintain a connection between two parties. There are 
many kinds of advertising, so the means for "connecting" can differ widely. Naturally, in 
order for SPQ to play this role, SPQ will need to know how to find the advertising; it will 
need data for enabling Reece to access the advertising. As an example, Addy can enter a 
URL for locating her webpage or video advertisement. As another example, Addy can 
enter her telephone number for placing a call to her. Therefore, SPQ's offer form can 
include a field for entering the data necessary for enabling Reece to access Addy's 
advertising. Depending on the implementation, SPQ will also include well-known means 
for using the data to enable Reece to access Addy's advertising. 

C. If SPQ stores an advertising message and outputs it to Reece then the offer form may 
or may not include a field for entering data for accessing the advertising. 

As discuused, SPQ may enable Addy to enter her ad into the system. For example, SPQ 
may enable her to enter a text ad into the system, which is outputted to Reece when she 
accepts Addy's EVQ offer. In this case, the system may automatically associate the text 
ad with the offer data. The same goes if the ad is an audio or video ad. In most 
implementations, if the system includes means for entering an ad into the system, it will 
also include means for automatically associating the ad with the corresponding offer data. 
However, in certain implementations, the offer form may include a field in which Addy 
states the name or location of the ad within SPQ so that SPQ can find and output it. 
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Field 5: Amount of EV Payment 



Through SPQ, an advertiser offers to pay recipients by the EV payment method — by an 
EV payment bet, that is. Accordingly, the offer form includes a field for stating the EV 
payment due to a recipient who accepts the EVQ offer and meets the offer conditions. 

The payoff of the EV payment bet can be a static amount, such as $1,000. Or, the payoff 
amount can be determined by a payoff multiple of the EV payment, such as, lOOOx. 
(Note, it is desirable in certain implementations for the payoff to combine both methods, 
such that the recipient must win two EV payment bets to receive the payoff.) 

The payoff can be standard, or the offer form can include a field for enabling Addy to 
specify the payoff amount or the payoff multiple. 

It is also possible for SPQ to enable recipients to set the payoff. 

(For simplicity, will assume that the payoff amount and payoff multiple are standard.) 

Field 6: Time Period for Notification of Winning 

Winners of EV payment bets need to be notified that they have won. The time period 
from acceptance of an EVQ offer to the notification of winning depends upon the 
implementation. Therefore, the offer form can include a field for enabling Addy to 
specify when a winning recipient is notified. Alternatively, this field is omitted and the 
time period is set by default, or by a system rule that is standard. One other possibility to 
enable the recipient to determine when he is notified. 
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Field 7: EVQ Offer Conditions 



The offer form will also include fields for defining the target to be paid, that is, for stating 
the conditions that Reece must meet in order to be paid. 

The system can enable Addy to define the conditions using standard elements, but these 
are far too varied to describe here. Continuing applications will give more detail. Suffice 
to say that there are innumerable ways of describing a qualified (a target) recipient. 

Conditions encompass not only the qualifications of a recipient but also other kinds of 
things, such as the kind of attention that a recipient must pay to an ad, and the time period 
of the EVQ offer. These are "boilerplate conditions" that can be part of any offer. Below 
we give just a two such conditions that apply to most pay-for-attention offers. 

Multiple Acceptances Condition 

The offer form can include a field for specifying how many times Reece can accept a 
payment offer. Various conditions are possible. For example, a one-time-only condition 
is possible. A variation enables Reece to accept an offer multiple times but to only be 
able to collect on one of those times. We do not delve into the possibilities because they 
are too various. Suffice to say that the offer form can enable Addy to select from standard 
conditions concerning how many times Reece is permitted to accept an offer. In certain 
implementations, such a condition can be enforced by SPQ in the recipient process. 

Attention Conditions 

The offer form can include a field for specifying the kind and amount of attention that 
Reece must pay. In certain cases, this condition can be enforced by SPQ in the recipient 
process. For example, a condition might be that Reece has to listen to a sales message 
over the phone for at least 60 seconds. If Reece does not pay that much attention, SPQ 
may be able to detect that fact and nullify the offer. In other cases, only an inspector can 
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verify whether the condition has been met. A variety of inspection possibilities exist, 
which are beside the point here. Suffice to say that the attention requirements can be 
stated in the offer form (alternatively, they can be stated outside the system). We should 
also note that there might be no enforceable attention condition. For example, Reece may 
be paid to look at a webpage. As long as SPQ registers that Reece has selected a 
hyperlink for the webpage, that selection may suffice to accept and fulfill the EVQ 
contract. Reece may not even glance at the page, and in fact the page may not even be 
successfully transmitted to Reece (a happens sometimes with webpages). 

Note: Regarding Text of Full Offer 

The offer form can also include a field in which Addy can put the full text, or a link to the 
full text, of her EVQ offer. This feature is useful so that an inspector can read the all the 
terms of the offer to determine whether or not Reece has met the terms. It is also 
necessary in cases where SPQ makes it possible to for Reece to look up the full text of an 
offer. For example, Reece might see an EVQ offer in a magazine ad and may use the 
frontend of SPQ to accept the offer. While doing this he might want to see the full text of 
the offer, which may not have been spelled out in the magazine ad. 
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Important Aside: Terms and Conditions Can Be Outside the System 

Some or all of the terms and conditions of an offer may be stated outside of the system. 
In fact, none of the conditions has to be stated by an advertiser in an offer form. 
Technically speaking, they can all be standard conditions or conditions set outside the 
system, and understood by advertisers and recipients. 

In this case, where the conditions are not stated in the offer form, they still have to be 
identified by the system so that accepted offers can be processed. Thus, the SPQ offer 
form will at least have a field enabling Addy to identify the offer, wherever it may reside. 

Each individual term or condition given above can be stated outside the system and can 
be associated simply with the name of an offer, and hence does not need to be specified 
in an offer form. Thus, the fields of an offer form depend on the implementation. 

Field 8: Controls 

The offer form can also include fields or commands for controlling the presentation of the 
offer to recipients. These include: 

• An on/off command — that is, a suspend/reactivate command — that causes the offer 
to be shown or not to recipients. 

• A budget field stating that an offer is to be suspended after a specified number of 
acceptances or after a specified amount of money has been spent by the advertiser. 

• An expiration field that signifies that an offer is to expire at a given time. 
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3. Steps for Making the Offer Accessible to Recipients 

As discussed above, SPQ can enable Addy to identify her offer so that it can be 
associated with a data input by Reece. If SPQ enables Reece to find/select/accept Addy's 
offer though a button or other such input, then SPQ will also include a step by which 
Addy associates her offer with the button, as for example, enabling her to associate a 
hyperlink with the offer. The possibilities are wide, depending on the interface being 
used, and the options are well known. 

The other general approach is to enable Reece to find the offer through search means. If 
search means are employed, then Addy effectively takes the step of making her offer 
accessible by entering the offer into SPQ. 

If SPQ enables Reece to find an offer by search means, SPQ can also enable him to see 
the offer, or part of the offer, and then enter a separate input — such as pressing a button — 
to accept the offer. To repeat, these steps are well known and need no elaboration. 

4. Steps for Modifying or Deleting an Offer 

As discussed, the advertiser process consists mainly of steps for enabling Addy to fill in 
an offer form. Naturally, the advertiser process will also include steps for enabling Addy 
to find a stored offer and to modify or delete it. These steps are well known and need no 
elaboration. 
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5. Steps for Enabling Payment by an Advertiser 

Transferring actual payments may or may not be part of SPQ's functionality. 

SPQ may simply register obligations by advertisers to qualified recipients. It is then up to 
the advertisers to make actual payment. In other words, SPQ can simply be an accounting 
machine that does not actually transact funds, but merely states how much is owed by an 
advertiser and to whom it is owed. 

Alternatively, SPQ can take funds from an advertiser and distribute these, as is 
called for in the recipient process. In this case, the advertiser process will also 
include well-known steps for creating an advertiser debit account or credit 
account. In this case, SPQ will also include steps for accepting payment through 
well-known methods for accepting money through a variety of payment vehicles. 

In the section on payment processes, we describe functionality for transacting 
actual payments from advertisers to recipients, but we recognize that SPQ can be 
implemented without this functionality. 
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1.3 ELEMENTS and STEPS for the RECIPIENT PROCESS 



Introduction 

Whereas the advertiser process mainly involves storing data defining an EVQ offer, the 
recipient process involves what SPQ does when a recipient finds an offer and accepts it. 

Frontend Options for Enabling a Recipient to Find an Offer 

As discussed, SPQ can have one or more frontend interfaces that enable recipients to find 
offers. In this section we are not concerned with interfaces, just with the key steps of the 
recipient process. We will assume that Reece has used the SPQ frontend and entered a 
simple command or search criteria to enable SPQ to find an offer. 
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Overview of the Key Steps of the Recipient Process 

Below we give the key steps SPQ executes in the recipient process and we define the data 
elements needed. (We note that some of the steps can be executed in a different order 
than the one presented, depending on the implementation. Those skilled in the art will 
readily see where the sequence of steps can be changed.) The steps are as follows: 

1 . Register the recipient's identity. 

2. Find an EVQ offer in response to the recipient's input. 

3. Register acceptance of the offer (register that the recipient has been exposed to the 
associated advertising or has taken the necessary steps to being exposed). 

4. Possibly, "connect" the recipient with the advertising or output the advertising. 

5. Possibly verify that attention is paid to the advertising. 

6. Apply the rule in effect regarding multiple acceptances. 

7. Execute the EV payment bet specified in the offer. 

8. Record the results of the EV payment bet. 

9. If the acceptor has won the bet: 

a. Inform him that he has won, 

b. Receive and register the acceptor's claim to be paid the payoff, 

c. Generate statistics about how many winners were also claimants, 

d. Pass the claim to the inspector process. 

We elaborate on these steps below. (We discuss payment steps in Section 1.5.) 
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1. Register the recipient's identity. 



As part of the recipient process, SPQ must identify the recipient so that he can be paid in 
the event that he wins the right to collect the payoff. 

Registering Reece's identity is also necessary so that duplicate acceptances of an offer 
can be purged, depending on the conditions governing multiple acceptances. And, Reece 
must be uniquely and legally identified so that he cannot successfully use multiple 
identities. That is to say, if he collects a payoff, the system needs to credit the payment to 
his legal name, a unique name. 

Reece can be identified before he enters search criteria into SPQ, as is the case when 
Reece logs on to SPQ and then begins searching. SPQ will have identified him before the 
search. Alternatively, SPQ can identify him after he has entered search criteria and SPQ 
has presented an offer to him. In this case, SPQ can present a form for entering his ID 
data after he has accepted an offer. The exact sequence of registering ID data depends on 
the implementation. SPQ can incorporate the gamut of methods used to uniquely identify 
users of a system, and these need no elaboration. 

2. Find the offer in response to the recipient's input. 

SPQ finds the offer that corresponds to the command or search criteria Reece has entered. 
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3. Register the acceptance of the offer. 



How SPQ enables Reece to accept an EVQ offer depends on the implementation. There 
are many possibilities and it is not possible to state a general rule to cover all the ways it 
is possible to configure a system to register the acceptance of a pay-for-attention offer. 

In general SPQ registers an acceptance when it registers that the recipient has entered a 
command to be exposed to an advertising message or when it registers that the recipient 
has been exposed to an advertising message. We give some examples to illustrate. 

Reece might arrive at a webpage and may signify acceptance by pressing a button that 
launches a webpage (or audio or video) ad. 

Or Reece may enter search criteria into a search form and then SPQ may present him 
with an offer, which he can then accept. 

Or the search criteria might lead to an ad being output to him, which could signify 
acceptance of the offer. Indeed, requesting a page with multiple, distinct messages may 
signify acceptance of multiple offers — an acceptance for each message. For example, 
SPQ may output a list of classified ads, each ad signifying a different offer from a 
different advertiser (we will delve into this possibility in a future specification). 

Or Reece might call Addy through a telephone switch that reports to SPQ that Reece 
called Addy. 

Or Reece might call Addy and Addy might then enter into SPQ that Reece called. 

Or, SPQ might output an ad to Reece by email and register the sending of the email as 
acceptance of the offer. Or, the clicking of a link in the email might signify acceptance. 
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There are many possible interfaces and many possible acceptance sequences. 

A recipient who accepts an offer will be called an acceptor. 

An offer that is accepted will be called an EVQ contract. 

The data object or file where SPQ registers Reece's acceptance will be called an 
acceptance record. SPQ creates an acceptance record per offer for an acceptor. 

The acceptance record will include the following data (or pointers to the data): 
-the recipient's ID data, 

-the name (or other data for identifying) of the offer, 

-the terms of the offer (as defined in by the offer form data), 

—the time of acceptance. 

If it is the acceptor's first time accepting the offer, the record will only contain data from 
this first acceptance. If Reece has accepted the offer before then SPQ will note and 
timestamp each additional acceptance in the record. Thus, an acceptance record can 
include multiple acceptances of the same offer. The validity of these acceptances will 
depend on the terms of the offer. 
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4. Possibly, enable the recipient to access the advertiser's advertising or possibly 
output the advertising. 

As discussed in the description of the advertiser process, in certain implementations, one 
of SPQ's functions will be to "connect" Reece to Addy's advertising — to enable Reece to 
access Addy's advertising, that is. In such implementations, a key step in the recipient 
process will be making this connection (or providing the necessary data, such as an html 
link). Thus, SPQ will provide Reece with means for accessing Addy's advertising, and 
will enable Reece to access her advertising. These means will depend on the frontend that 
is being used (see Chapter 2, which supplies some examples). 

Also as discussed, in certain implementations, SPQ may store Addy's advertising. In 
such implementations a key step in the recipient process will be to output the advertising. 

5. Possibly verify that attention is paid. 

If SPQ connects Reece to Addy's advertising, SPQ may enforce the attention condition, 
if any, stipulated in the offer form. For example if calls are made through SPQ, SPQ 
might be able to enforce a time requirement per phone call. 

Whether an attention condition is checked at this stage depends on the implementation. If 
so, and if Reece has violated the attention condition, then SPQ can alert him telling him 
that he is ineligible to collect on the payment. 

If SPQ has a step for checking whether attention was paid, this step can come before the 
acceptance is registered. If the recipient has not paid adequate attention then the 
acceptance is not registered. 
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Alternatively, the registration of the acceptance can come first and then it can be 
canceled, if the recipient does not pay adequate attention. 

There are two general ways to verify attention. In one way, SPQ registers what we will 
call verification data that can be understood by SPQ and that signifies whether Reece has 
paid attention to Addy's advertising or not. Verification data is a general idea that we 
cannot define precisely. It, too, depends upon the implementation. 

For example, the phone switch that handles a call between Reece and Addy might send a 
signal telling SPQ that the phone call was long enough (or not long enough) to pass the 
attention condition of Addy's pay-the-caller offer. 

As another example, Reece might be required to answer a question about Addy's 
advertising to prove that he indeed paid attention, in which case SPQ could include 
means for receiving and affirming a correct answer and rejecting an incorrect answer. 

The second general way is to enable Reece to submit evidence of paying attention that 
cannot be processed automatically — that cannot be understood — by SPQ but that 
requires a human judge. In this case, SPQ stores the evidence in Reece's acceptance 
record and then, if Reece wins the EV payment bet, a human inspector determines 
whether Reece paid attention or not. For example, Reece can look at Addy's webpage 
and then answer the following question: "What is the main benefit of Addy's product 
according to this ad." Reece can submit his answer by an email or by a form and SPQ can 
store the answer in the acceptance record, to be reviewed in the inspector process, if 
Reece wins the EV payment bet. 
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6. Apply the rule in effect regarding multiple acceptances. 

An EVQ offer will include a rule or rules — conditions — spelling out what happens if 
Reece accepts an offer multiple times. The rule can be a meta-rule of the system that 
applies to all EVQ offers or it can depend on the particular offer. A variety of rules are 
possible for determining whether an acceptance is valid. 

By valid we mean that an EV payment bet is executed for that acceptance to determine 
whether Reece wins the right to collect the payoff. We can think of an acceptance as a 
ticket that is valid or not in the sense that it gives the owner the right to participate in a 
random number selection that then determines whether the owner has the right to collect 
a payoff. An acceptance that can be canceled ("scratched") depending on the rule that 
applies for multiple acceptances of an EVQ offer. 

For example, one rule can be that the first acceptance is the valid one, and that any 
acceptance after that does not count. Another rule can be that the last acceptance is the 
one that counts. Another rule can be that if the EV of the EVQ offer changes, Reece can 
be eligible to collect on the acceptance of the offer with the highest EV. Another rule can 
be that Reece gets one valid acceptance per a period of time. Yet another rule can be that 
all the acceptances count but if Reece wins the payoff, the payoff is divided by the 
number of acceptances. 

SPQ needs to enforce whatever rule applies given the EVQ offer or the system meta- 
rules. Thus, SPQ will include a step for checking the acceptance record and, based upon 
the rule that is in effect, select only the acceptance that is valid for the next step of 
determining whether the acceptance is a winner. Alternatively, before registering an 
acceptance, SPQ can simply check whether it can be valid under the multiple acceptances 
rule that applies, and if the acceptance cannot be valid, then SPQ may not register it at all. 
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(Note: The rules governing multiple acceptances can be subtle and it may be necessary to 
verify compliance in the inspector process where, in certain cases, it becomes evident that 
the recipient has tried to evade the rules. Hence, certain acceptance rules can be enforced 
before the EV payment bet is executed for a given acceptance and others can be enforced 
afterward, in the inspector process.) 

7. Execute the EV payment bet specified by the offer (select a random number from 
a range dictated by the E V payment and the payoff or by the payoff multiple). 

Once SPQ has determined that an acceptance is provisionally valid, it needs to determine 
whether Reece has won the right to collect the payoff— that is, whether Reece has won 
the EV payment bet. Thus, SPQ generates a random integer in the range dictated by the 
EV payment and the specified payoff or as dictated by the specified payoff multiple. 

(In the case of a static payoff, an integer is selected in a range from 1 -payoff, where the 
payoff is divided into integer units, and the recipient wins if the integer falls in the range 
1-EV. In the case of a specified payoff multiple, N, where N is an integer, the probability 
of winning is 1/N, so an integer is selected in the range of 1-N and the recipient wins if a 
single, pre-determined number comes up, say, 'T\ If N is not an integer, then the 
procedure is slightly modified, which needs no elaboration.) 

(Note: a separate computer could do the random selection. If so, we would still consider 
it part of SPQ for our purposes of describing SPQ's core processes— which can be 
performed by one computer or linked computers that communicate with each other.) 
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8. Record the results of the EV payment bet 

SPQ can record the winners and losers or it may only keep a record of the winners. 
9a. If he has won, inform the acceptor that he has won. 

If an acceptor wins an EV payment bet, SPQ notifies him, say, by sending him an email 
telling him that he has won the bet and that he must submit proof that he is qualified to 
collect the payoff— i.e., that he is a qualified recipient. 

SPQ can inform the acceptor in other ways, e.g., if he uses an SPQ website, SPQ can 
identify him when he logs on and inform him of his win then. This method is more 
appropriate than email in certain situations. 

(As stated in the advertiser discussion, the timing of the notification is determined by a 
standard rule, or by the time period specified by the advertiser in the offer form or, by the 
recipient's choice, depending on the implementation.) 

At the notification stage SPQ can also output a claim form to the winner for entering 
proof of qualification data. We cannot describe a universal claim form because of the 
variety of possible qualifications. However, one possible generic claim form may simply 
ask him whether he does indeed qualify to be paid the payoff, and if he responds "yes", 
then an inspector may investigate the claim. 

(A separate computer that is linked to SPQ may handle the alert process. As noted, 
distributing a function does not change the core process. The point is that when SPQ 
determines that Reece is a winner, it informs a sub-process for alerting him.) 
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We note that in certain implementations the claim steps may be obviated completely such 
that SPQ sends the case directly to an inspector upon determining that an acceptor has 
won. This option may be appropriate especially when the payoff is very large. 

9b. Receive and register the acceptor's claim. 

The submission of qualification data, or the assertion that the acceptor is qualified, will 
be called a claim. 

Those acceptors who submit claims will be called claimants. 

If SPQ outputs a claim form when it alerts Reece that he has won, then SPQ will receive 
a claim back from him through this form. When SPQ receives a claim this way, it 
registers the claim, which will include an ID number that associates the claim with the 
corresponding offer data and acceptance record data. 

Another possibility is that Reece submits his claim by paper mail and that a system 
operator then logs the claim into the system. In this case, SPQ will still register the claim 
as if Reece himself entered the data. 

9c. Generate statistics about how many winners were also claimants. 

SPQ can periodically tabulate and output statistics that show the percentage of winners 
who were also claimants. 

Later, at the end of the inspector process, SPQ can also calculate how many claimants 
were deemed to be qualified recipients (those who collected their winnings). This data in 
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particular is important for advertisers and it can be critical for developing discount rate 
statistics (discussed in Section 1.5). 

9d. Pass the claim to the inspector process. 

After registering a claim, SPQ passes it to the inspector process (see Section 1.4). 



Payment Steps in the Recipient Process 

SPQ can register payment obligations in a few different ways. 

We describe possible payment processes in Section 1.5 but note that in most 
implementations, the payment registration steps take place in the recipient process if SPQ 
assumes payoff risk, which we believe will be most common in practice. 

The steps are described in Section 1.5 and their placement in the recipient process can 
easily be seen by those skilled in the art. 
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1.4 ELEMENTS and STEPS for the INSPECTOR PROCESS 



At the end of the recipient process, if Reece has won the EV payment bet, he may submit 
a claim to collect the payoff stated in the offer he has accepted. 

SPQ registers the claim and makes it available for an inspector (Vera) to examine. Vera f s 
role is to verify whether Reece has fulfilled the conditions of the PT contract. 

(We note that in certain implementations the inspection process can be automated.) 

In the inspector process, SPQ can assign the claim to Vera. Or SPQ can enable Vera to 
find the claim and assign herself. Either way, Vera calls up this claim and, after 
examining the claim, enters a decision as to whether Reece has fulfilled the conditions of 
the offer. Thus, the inspector process includes the following elements and steps: 

1 . SPQ authenticates an inspector. 

2. SPQ enables the inspector to retrieve a claim record, which includes the following data 
elements (defined in Section 1.3): 

-the offer form data, or a link to this data, 
-the recipient ID data, or a link to this data, 
-the acceptance data, or a link to this data, 
-the claim data, or a link to this data. 

3. SPQ enables the inspector to call up an inspection report form, which includes fields 
for the following information: 
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a) The name of the inspector. This field is for registering which inspector is handling the 
claim. SPQ can automatically fill in this field using the inspector log-in. 

b) The claim locator number. This field is for identifying the claim. SPQ can 
automatically fill in this field. 

c) The decision. This field is for stating whether the claim is approved or rejected. 

d) The explanation. If the claim is rejected, the inspector will usually need to explain 
why. Thus the inspection report form will include a field for supplying a text explanation 
of why the claim was rejected. The explanation can be a "form letter' 1 explanation that 
can be selected by the inspector. 

4. When the inspector enters a decision, SPQ stores and timestamps the inspection report 
and associates the report with the offer data and acceptance data for the recipient. 

5. 

If the claim is rejected, SPQ executes the following steps: 

-notifies the recipient telling him of the rejection and, in the notice, includes the 
explanation stored in the explanation field of the inspection form. 

If the claim is approved, SPQ can execute the payment transaction steps spelled out in 

Section 1.5. At minimum SPQ: 

-registers that the recipient is owed the payoff amount stated in the offer, 
-notifies the recipient telling him he has won and is owed the payoff, 
-sends notification of the payoff owed the recipient to a process (inside SPQ or 
outside SPQ) for paying the recipient or, simply sends notification to the 
advertiser that she owes the recipient the payoff 



42 



Steps for Paying the Costs of the Inspection Process 

Having Vera do an inspection costs money. The system can pay the costs in various ways 
and can assess a cost to advertisers and winning recipients. 

We do not delve into the variety of payment schemes for defraying the costs of 
inspection. We assume that, like the other operations of the system, the costs must be 
defrayed and are paid by the advertisers and recipients, directly or indirectly. 

However, we do note that inspection costs can be reduced by making claimants pay for 
the inspection, or pay a deposit to guarantee that their claims are valid. This measure will 
deter non-qualified recipients from making claims. Thus, an important step in the 
inspection process, in certain implementations, is to include a step for taking a 
payment/deposit from a claimant, when the claimant submits a claim. 
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1.5 REGISTERING ADVERTISER PAYMENTS 



In Section 1 .4, we said that when the inspector approves a claim, SPQ registers that the 
recipient is owed the payoff. However, we did not describe steps for actually paying the 
recipient and for getting payment from the advertiser. 

SPQ is a system in which qualified recipients (Q-recipients) are paid through EVPM bets, 
meaning that the amounts actually paid are payoff amounts that may be quite large. How 
SPQ enables payoff payments to be transacted from advertisers to Q-recipients depends 
on whether the advertiser assumes the payoff risk in the EVPM bets or whether SPQ 
assumes the risk. We discuss these possibilities below. 

Note: In all cases below, if SPQ collects payment from advertisers, SPQ will include 
well-known debit and/or credit account processes. Further, SPQ will include well-known 
mechanisms for accepting payment and for notifying an advertiser when her account has 
a low balance or an overdue balance. Further, SPQ will include well-known mechanisms 
for suspending an advertiser's offer when her balance has fallen below a threshold. 
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Case 1. Advertiser Assumes the Risk in the EVPM Bets 

If the advertiser assumes the payoff risk, SPQ does not necessarily have to collect 
payment from her. SPQ can be an accounting machine in the sense that it registers 
payment obligations but does not transfer actual payment. 

In this case, SPQ includes steps for notifying advertisers of their payment obligations and 
for notifying winning Q-recipients that they are owed the relevant payoff amount from a 
given advertiser. 

For example, assume that IBM is paying recipients to view a commercial, and assume 
that Reece wins $10,000 in an EVPM bet based on this offer and, assume that Reece 
turns out to be a Q-recipient. Then, SPQ may simply notify Reece that IBM owes him 
$10,000 and will notify IBM that it owes Reece $10,000. 

Alternatively, SPQ can include means for transferring payoffs from advertisers to 
winning Q-recipients. These means include steps for: 

-establishing a debit (or credit) account for an advertiser, 

- receiving funds into in this account and, 

- transferring a payoff from an advertiser account to a Q-recipient. 
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Case 2. SPQ Assumes the Risk in the EVPM Bets 

If SPQ assumes the payoff risk, it will include means discussed above for establishing an 
advertiser payment account. Each time a recipient validly accepts an advertiser's offer, 
SPQ will deduct money from the advertiser's payment (debit) account and transfer it into 
an SPQ account, and from that SPQ account, the system will pay recipients. 

But the process is more complicated than that; it is different from a conventional payment 
transfer system. The problem is that Addy is offering EV payments only to Q-recipients, 
but recipients who accept her offer will include Q-recipients and non-qualified recipients. 

Assume that Addy offers Q-recipients $1 to call her flower shop. Now, assume that 2000 
recipients accept her offer. 

How much does Addy owe SPQ? If she pays $1 per acceptance of her offer, that is not 
fair because she is only supposed to pay for Q-recipients. She does not know, and SPQ 
does not know, what percentage of acceptors were Q-recipients. 

SPQ cannot know if a particular acceptor is a Q-recipient unless the uncertainty is 
resolved by the acceptor winning an EV payment bet. 

Therefore, to compensate for non-qualified acceptors, SPQ must apply a discount factor 
to the EV amount that Addy offers to Q-recipients. This discount factor is applied to each 
valid acceptance. Each time a recipient accepts her offer, Addy would not owe SPQ the 
full amount of the EV payment stated in the offer, but a discounted rate. For example, if 
the EV amount offered to Q-recipients is $1 and the discount factor is 10%, then SPQ 
registers that Addy owes 10 cents per valid acceptance. 
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The goal in a discount factor is to represent the percentage of acceptors who are Q- 
recipients. To arrive at a fair discount factor, the general idea is to gather statistics on 
what percentage of acceptors are Q-recipients. 

SPQ may include one or more formulas to determine the discount factor for a given 
advertiser and the advertiser's offer. The formulas will use data on how many acceptors 
convert into winning Q-recipients (how many winning acceptors are Q-recipients). These 
statistics can be gathered from the responses to offers within SPQ that are similar to 
Addy's offer. SPQ can feed this response data into the discount formula(s). 

Other methods, such as survey methods can be used as well to yield discount factor data 
to be fed into discount formulas as well. 

The point here is that if SPQ assumes the payoff risk it will include: 

-a discount formula (or formulas) for arriving at a discount factor, to be applied to 
the EV amount that is offered in an EVQ offer. 

(Alternatively, in certain implementations, SPQ will include not include a discount 

formula, but will include means for enabling a system administrator to enter a discount 

factor into the system.) 

Further, in the recipient process, when a recipient accepts an offer, SPQ will: 
-apply the appropriate discount factor to the EV payment, 
-deduct the resulting amount from the advertiser's debit account, 
-transfer the amount to an SPQ account that is used to pay winning Q-recipients. 

Further, in the inspector process, when an the inspector approves an acceptor's claim, 
SPQ will: 

-register that the acceptor is owed the payoff from the SPQ account that is used to 
pay winning Q-recipients. 
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Case 3. SPQ Enables the Advertiser to Choose to Take the Risk in EVPM Bets 

SPQ can enable Addy to choose whether or not to assume the payoff risk. The system 
would simply include both kinds of payment processes discussed above. In this case, 
SPQ could enable Addy to check a box in the process of establishing her account in 
which she signifies that she will take the payoff risk in all payment offers to recipients. 
Alternatively, the SPQ offer form can include a checkbox where Addy signifies that she 
will take the payoff risk for the particular offer. 
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1.6 PRODUCING ADVERTISER REPORTS 



A process for producing reports for advertisers is not strictly necessary for the minimal 
operation of SPQ. Yet, it is so useful that we note, here in Chapter 1, that SPQ will 
include steps for enabling Addy to view: 

a) how many unique recipients accepted her offer, 

b) possibly, the identities of those recipients, 

c) how many of those recipients won the EVPM bets, 

d) how many of the winners turned out to be qualified recipients, 

e) how much she has spent on EVQ offers (see Section 1.5). 
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1.7 ENTERING an AD 



As noted in the discussion of the advertiser process and the recipient process, SPQ 
may include functionality of storing and outputting ads. This kind of functionality 
is well known. There are certain implementations of SPQ in which having an 
advertiser enter an ad, and having SPQ output that ad to recipients, is integral to 
the total system, and does create a novel whole. 

How SPQ enables advertisers to enter ads depends on the implementation and 
needs no elaboration. 

Entering and storing an ad can be an additional step in the advertiser process, or it 
can be a separate process done separately from entering an offer. 

If SPQ enables Addy to enter an ad into the system, it will require well-known 
means for associating the ad with her EVQ offer, and for enabling Reece to output 
the ad upon accepting Addy's offer. 
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CHAPTER 2 
EMBODIMENTS for VARIOUS MEDIA 



2.0 INTRODUCTION to CHAPTER 2 

Problem to Be Solved 

How to implement SPQ to suit different kinds of attention — different kinds of media? 
Solution 

The core process can be adapted to different advertising media. The specific solutions 
will depend upon the specific kind of advertising and media involved. In this chapter we 
describe embodiments for adapting the core process to different kinds of advertising. 

Organization of this Section 

For convenience, we will divide advertising into two general, imprecise types: 

(1) one-way advertising (webpage, audio, video ads and email ads) 

(2) two-way "conversation" advertising (phone calls and meetings). 

For each of both of these types, multiple embodiments can be constructed. We cannot be 
exhaustive in describing these embodiments. The key differences between embodiments 
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in the advertiser process have to do with methods for linking ads to offers (and for 
entering ads, if SPQ stores and outputs ads). The key differences in the recipient process 
revolve around three sub-processes: 

a) registering the recipient's identity, 

b) exposing the recipient to the message, which may or may not involve SPQ, 

c) enforcing the recipient's attention, which may or may not involve SPQ. 

Assumptions for Visualizing the Invention 

For the sake of concreteness in visualizing the invention, we will imagine that SPQ is 
used by multiple advertisers to post EVQ offers. 

We can further imagine that the request interface enables Reece to find an offer by 
pressing a button. In this case, the pressing of the button would correspond to an offer ID 
that would then be communicated to the SPQ database to identify a specific offer. 

Or, we can imagine that recipients identify an offer by entering a code into an SPQ search 
interface. For example, IBM may state in a print ad, Call 1-800-r-e-a-l-b-u-y and enter 
"I-B-M" at the appropriate prompt in order to get paid $2 to talk to one of our 
representatives. In this case, the code I-B-M would correspond to an offer that IBM has 
entered into SPQ in the advertiser process. 

The general idea is that the central database can serve a variety of frontends that are used 
to interface with recipients. 
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When we describe embodiments, we will strive to not repeat the description of Chapter 1. 
We will often recap what was said in Chapter 1, for the sake of clarity, but will try to add 
matter only where necessary. Where we say, "remains the same", we will mean that we 
have nothing to add to what was explained in Chapter 1 . 

(Note: we will only describe two embodiments in this specification, but will may add to 
these in a later, continuing application.) 

Contents of this Chapter 

Section 2. 1 An SPQ embodiment for paying recipients to view webpage ads 
Section 2.2 An SPQ embodiment for paying recipients to call an advertiser 
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2.1 SPQ for Webpage, Audio and Video Ads 



2.10 Introduction to Section 2.1 

Problems 

How to pay a qualified recipient for paying attention to a webpage ad? Similarly, how to 
pay a qualified recipient for paying attention to an audio or video ad? 

Solutions 

Embodiments of SPQ's core processes can enable advertisers to pay qualified recipients 
for paying attention to webpage ads. In this section we describe one basic embodiment 
and features that can be added to it, as follows: 

2.11 An SPQ for Webpage Ads 

2.12 Features for Using Multiple Websites as Frontends for Recipients 

2.13 Attention Enforcement Features 
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2.11 An SPQ for Webpage Ads 



Scenario 

In this sub-section, we describe how the core processes are implemented as a directory 
system of EVQ offers that enables Q-recipients to be paid for viewing webpage ads. As 
an example of how this system might be used, we might imagine that a advertiser shows 
the lookup code in print ads much as she might show her phone number or her URL. 
Recipients could then go to the SPQ directory and enter the lookup code. (The directory 
could enable Reece to enter the advertiser's name, which could act as the lookup code. 
For example, she might show the code in a print ad, e.g., If you are going to join a health 
club in the next 20 days, go to realbuyers.net and enter "Bally 's Health Club " into the 
search engine. Multiple advertisers could use such a directory. (Note that SPQ-WA could 
also include search functions for enabling recipients to find lookup codes according to the 
name of the advertiser.) 

So, we imagine that Reece finds an offer by entering a lookup code into this directory. 

We will imagine that the system presents an offer to him by outputting a link that 
corresponds to the lookup code. When he selects the link, he accepts the corresponding 
EVQ offer and receives the corresponding ad. In other scenarios, simply entering the 
correct code may signify acceptance, and may cause the ad to be outputted to Reece. 

We will call this embodiment an SPQ for Webpage Ads (SPQ-WA). This name is a 
misnomer since the methods of this embodiment extend to any recipient-launched, "one- 
way" message — such as, a webpage ad, an audio ad, a video ad, or even an email ad. We 
use a webpage as the example ad message for the sake of concreteness. 
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2.11a The Advertiser Process for SPQ-WA 



Addy enters her offer into SPQ-WA through a website interface, using an offer form. 
Below, we describe the data she enters and how SPQ-WA uses it to enable Reece to 
accept her offer. We list the fields of an offer form, disclosed in Chapter 1, and add 
matter only as necessary. 

Field 1: Name Used by the Advertiser for the Offer Document 

Remains the same. 

Field 2: Data for Enabling Recipients to Find an Offer 

In the case of the SPQ-WA, under the scenario we have chosen, the data for finding 
Addy's offer is a lookup code specified by her. SPQ will check to insure that the code is 
unique to the system but it is up to Addy to decide what the code is. 

Field 3: Data for Accessing the Advertising 

In the case of an SPQ-WA, the data for accessing the advertising is a URL or an 
equivalent locator code. This address is presented as a link when Reece finds the offer. 
Reece can then select the link to receive the ad. (We do not mean to limit the application 
to URL's and corresponding webpages. The locator code enables an ad to be served to 
Reece from whatever ad server that the locator corresponds to — e.g., to an ad in an ad 
server in an interactive TV network.) 
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Field 4: Amount of EV Payment 

Remains the same. 

Field 5: Qualified Recipient Conditions 

Remain the same. We elaborate in sub-section 2.12. 

Field 6: Controls 

Remain the same. 

Additional Data Field for Entering a Description 

The offer form may include a field for enabling Addy to enter data describing herself and 
her offer. This descriptive data is then presented by SPQ to Reece when he finds her 
offer. For example, the link may be accompanied by a title or a blurb that previews the 
advertising message. 

Steps for Enabling Payment by an Advertiser 

Remain the same. 
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2. lib The Recipient Process for an SPQ-WA 



Here we recap the steps of the core recipient process, adding matter where necessary to 
describe how the process is implemented for an SPQ-WA embodiment. 

1. Register the recipient's identity. 

If it is Reece's first time using SPQ-WA, SPQ will present him with a form for creating a 
user account. The form will include fields for entering a user ID and password and 
additional ID data specifying Reece 's legal name. The goal is to have his log-on identity 
correspond to a single, legal identity so that he can be paid and so that he cannot use 
multiple identities. 

If Reece has already set up a user account, the system registers him through his user ID, 
or through a cookie mechanism, or through any other equivalent mechanism. (Methods 
for identifying users need to explanation here.) 

2. Find and present the offer. 

Reece enters the lookup code for Addy's EVQ offer and SPQ-FVR finds the offer and 
presents it as a link to be selected. 

We noted in the discussion of the offer form above that SPQ-WA may enable Addy to 
enter a description of herself and her offer. If so, the link would be accompanied by text 
describing the offer and/or describing Addy. 
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3. Register Acceptance of the Offer 

If Reece selects the link presented to him, he signifies acceptance of the offer. SPA 
registers the acceptance. 

Alternatively, it is possible that simply entering the lookup code will suffice as signifying 
acceptance of the offer. In this case, SPQ does not need to present a link to Reece. 

4. Provide the data to serve the advertiser's ad to the recipient ("connect" the 
recipient to the advertiser's advertising). 

If Reece selects the link presented to him, it causes SPQ to provide the data to serve the 
corresponding ad to Reece (i.e., SPQ can provide a re-direct to Reece's browser so that 
the browser requests the ad). The ad will be served by a machine controlled by Addy or 
another party, as specified by the ad locator that Addy supplied in the advertiser process. 

Alternatively, it is possible that simply entering the lookup code will suffice as a 
command by Reece to view the ad corresponding to the offer. In this case, SPQ does not 
need to present a link to Reece. SPQ will simply direct the ad to be served to Reece, as 
specified by the ad locator that Addy supplied in the advertiser process. 

(We note that it is possible for SPQ to serve the ad. If SPQ serves the ad, it will also 
require means for enabling Addy to load the ad into an SPQ ad server. This functionality 
would be integrated into the advertiser process.) 

5. Verify that attention is paid. 

Remains the same. 
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6. Apply the rule in effect regarding multiple acceptances. 

Remains the same. 

7. Select a random number from a range dictated by the EV payment and the payoff 
(or the payoff multiple). 

Remains the same. 

8. Record the results of the random number generation. 

Remains the same. 

9a. When the time requirement has expired, inform the acceptor that he has won. 

Remains the same. 

9b. Receive and register claim. 

Remains the same. 

9c. Pass the claim to the inspector process. 

Remains the same. 

Payment Steps in the Recipient Process 

Remain the same. Steps for transacting payment between advertisers and recipients can 
take place in the recipient process, as described in Chapter 1. 
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2.11c The Inspector Process for an SPQ-WA 



Remains the same. 



2.11d Payment Processes for an SPQ-WA 



Remain the same. 
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2. 12 Features for Using Multiple Websites as Frontends for Recipients 

SPQ-WA can also enable any properly configured website to be a frontend that recipients 
interact with. This embodiment is useful for an advertiser who wants to enable recipients 
to see and accept her EVQ offer at her website. 

Advertisers still enter their offers through a central SPQ website while the recipients 
interface with the distributed websites. 

In this scenario, SPQ includes means for receiving data from the frontend sites. This data 
set was described in previous sections. Accordingly, the frontend site will: 
—register ReeceV ID, 

—present Reece with a EVQ offer (and possibly enable him to find an offer), 
—register acceptance of the offer, 

—send the data it registers to the central SPQ-WA database. 

The frontend site must be configured with a program for sending this data to the central 
SPQ-WA database, or it must direct the recipient to retrieve forms from SPQ that submit 
data directly to the SPQ-WA database. 

(The data will be associated with the particular EVQ offer, of course). Correspondingly, 
the central database requires means for receiving this data from the frontend sites. 

A frontend site can include database functionality such that it holds an ID record of 
Reece. Alternatively, the frontend site can send Reece to an SPQ webpage that enables 
Reece to enter his ID data. Likewise, rather than send a set of data to the SPQ database, 
the frontend site might just send Reece to a SPQ webpage that is identified with the 
particular EVQ offer that Addy wants Reece to accept. The SPQ webpage can then 
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handle the necessary data registration. The point is that there are various well-known 
possibilities for implementing a frontend. 

The key aspect, for our purposes, is that the essential processes of the SPQ-WA database 
do not change. The database simply needs functionality for receiving data from recipients 
for a selecting EVQ offers from distinct, distributed frontends. 

The utility of the system can be greatly enhanced by this functionality because SPQ's 
frontend can be a set of distributed websites and not just a single, central directory site. 
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2.13 Attention Enforcement Features 



Where paying for attention is concerned, it is usually quite useful for Addy to be able to 
verify that Reece has actually viewed her ad. Where webpage and video ads are 
concerned, there are three basic attention verification methods: 

(1) measuring the time that Reece has spent viewing the ad, 

(2) requiring that Reece interact with the ad in a certain way, 

(3) requiring that Reece answer questions about the ad. 

These methods of verifying attention are well known. We discuss them briefly because 
attention verification features can be critical in a pay-for-attention system. The point, 
then, for our discussion is that SPQ-WA can include means for receiving attention 
verification data from the server that is serving the ad to Reece. This verification data 
will be keyed to the particular ad and corresponding EVQ offer. 

The verification data will be sent based on the time he has spent viewing the ad, or 
Reece 's interaction with the ad or, the answer Reece has provided, depending on the 
verification method that is used. 

If SPQ-WA has the task of verifying attention automatically then the data will have to be 
"understandable" by SPQ. It can be a simple verification signal (a "recipient paid 
attention" signal, sent by the ad server) or a set of data that has to be checked by SPQ. 

If SPQ verifies attention, it will cancel Reece 's acceptance of an EVQ offer if it does not 
receive a signal or a set of data that shows Reece has paid adequate attention. 

While we do not delve into particular methods for verifying Reece 5 s interaction with an 
ad and how a corresponding verification signal can be sent to SPQ, we will briefly 
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mention two general methods so that we can describe the mechanisms SPQ will include 
to enable Addy to use SPQ's attention verifying functionality. 

One method applies where the ad server follows a custom SPQ protocol for sending 
verification data to SPQ. In this case, the offer form can include a field for enabling Addy 
to specify a standard attention condition, such as interacting with Addy's ad in a certain 
way. According to the protocol, the attention verification signal will indicate whether or 
not Reece has met this condition. 

A second method is to enable Addy to enter a verification code into the offer form. In this 
method, we assume that when Reece views an ad, the ad gives him the opportunity to 
click on a link to indicate that he is viewing the ad. Selecting this link will cause the ad 
server to send a verification code to SPQ that is unique to the ad. Along with the code, 
the ad server can send the ad's address. Thus, when SPQ receives the code, it can check 
the offer data and match it with the ad's address and with the verification code. This data 
is not enough. 

(Equivalently to selecting a special "verification link", the ad server can enable Reece to 
enter a verification code into a webform that enables the code to be submitted to SPQ. 
The verification code could be hidden in the ad, so that Reece proves he has seen the ad 
because he has found and entered the appropriate code.) 

In order for SPQ to verify that Reece has been viewing, SPQ must also receive Reece' s 
ID back from the ad server. Therefore, we also assume that when SPQ enables Reece to 
be served the ad, it sends a code to the ad server to identify Reece. The ad server sends 
this recipient ID back to SPQ along with the verification code and the ad address. With 
these data, SPQ can register that Reece has fulfilled the attention condition. 
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Finally, there is another method of verifying attention, which is different and was 
discussed in Chapter 1 . SPQ can enable recipients to provide answers to questions about 
an ad. The answers may be machine verifiable, in which case they are equivalent to the 
verification code, discussed above. But, if the answers can only be judged by a human, 
then SPQ stores the evidence — the answer(s) — as part of the acceptance record, and 
enables an inspector to judge the evidence only if the recipient wins the EV payment bet 
for the offer. That means that human inspection can be done cost-effectively. This 
method of attention verification is novel because it uses the system's probabilistic 
inspection process to enable human verification of a recipient's attention. 
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2.2 SPQ for PHONE CALLS 



2.20 Introduction to Section 2.2 

Problems to Be Solved 

How to implement SPQ to pay a qualified recipient for calling an advertiser? And, how to 
pay a qualified recipient for taking a call from an advertiser? 

Solutions 

Different kinds of embodiments of SPQ can enable advertisers to pay Q-recipients for 
paying attention over the phone. In this section, we describe just one embodiment: 

2.21 An SPQ utilizing an interactive voice response phone switch 
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2.21 An SPQ Utilizing an Interactive Voice Response Phone Switch 



Scenario 

One way that SPQ can enable an advertiser to pay Q-recipients for calling is to have 
recipients call an interactive voice response (IVR) system linked to a phone switch that 
registers the recipients and routes calls to the advertiser. 

By phone switch we mean to encompass a variety of switches/routers for registering a 
calling party, registering a receiving party, transmitting a call between the two parties 
and, registering the duration of a call. The channel or protocol for transmitting the call is 
irrelevant for our purposes. The concept of a "switch" for our purposes applies equally 
whether the network being used is a network that opens a dedicated circuit between two 
parties, or a network that uses a protocol, such as the TCP/IP, to transmit packets. 

Under our IVR switch scenario, Addy enters her offer at an SPQ website that is the 
frontend for entering offers. The SPQ website then uploads the number to the switch. Her 
phone number then goes on a list of authorized numbers, maintained by the switch. These 
are the numbers that the switch will connect callers to. 

Under this scenario, Reece can then accept Addy's offer using the frontend for recipients, 
which is an IVR system. For example, Addy could advertise her EVQ offer in a magazine 
ad that states, Are you are a Q-recipient? We 11 pay you $2 to call us. Call 800-Realbuy 
and enter code #202-333-7777. 800-Realbuy in this situation would be the phone 
number for the IVR frontend that recipients would interact with. 



68 



SPQ's IVR frontend and phone switch register Reece's ID data, capture the code that he 
enters, and route the call to Addy's phone number. 

In addition to completing the call, the phone switch registers the length of the call. 
Importantly, this data enables SPQ to enforce the attention condition that is implicit or 
explicit in Addy's offer — e.g., she might specify that Reece has to stay on the phone for 
60 seconds or more in order to collect an EV payment. 

The IVR frontend does not have to process the data it registers; it can simply send the 
data to the central SPQ database, which then executes the rest of the recipient process. In 
this sub-section, we will describe the steps that SPQ takes under this scenario. 

We will call this embodiment SPQ Using an IVR Switch or the IVR Switch. 
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2.21a The Advertiser Process in which SPQ Uses an IVR switch 



In the IVR Switch embodiment, Addy enters her offer into SPQ through a website 
interface, using an offer form. Below, we describe the data she enters and how SPQ uses 
it to enable Reece to accept her offer. We list the fields of an offer sheet form, disclosed 
in Chapter 1, and add descriptive matter only as necessary. 

Field 1: Name Used by the Advertiser for the Offer Document 

Remains the same. 

Field 2: Data for Enabling Recipients to Find an Offer 

In the case of an IVR switch embodiment, the data for finding and accepting Addy's offer 
is a lookup code specified by Addy that corresponds uniquely to an offer or offers from 
her. We will assume, for simplicity and user-friendliness, that the code is the phone 
number that she wants Reece to call. 

In certain situations, Addy may have different EVQ offers that apply to the same phone 
number, and so, SPQ can enable her to distinguish between offers by adding an extra 
number to her phone number — e.g., 202-222-7777-1, 202-222-7777-2, and so on. 
(Addy's payment offer may vary depending on the amount that Reece spends. This kind 
of "multi-offer" does not affect the lookup code.) 
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Field 3: Data for Accessing the Advertising 

In the case of an IVR switch, the data for accessing the advertising is the phone number 
that Addy wants Reece to call. (If the phone number does not also serve as the lookup 
code, then Addy must enter the phone number into a phone number field.) 

The SPQ database must then send the number to the switch, which requires means for 
storing the number in a list of authorized numbers. The SPQ database must also be able 
to send a cancellation notice to the switch that causes a number to be canceled from the 
list of authorized numbers. 

Field 4: Amount of EV Payment 

Remains the same. 

Field 5: Qualified Recipient Conditions 

The discussion of these conditions remains the same but let us elaborate. Where paying 
for a Q-recipient to call, the key attention condition is time spent on the call. This time 
period may be standard or set by Addy. If Addy sets it, there will be a field for enabling 
her to do so. Another condition that is possible is a time-of-day condition, in which Addy 
specifies a certain time period for Reece to call. Like the duration-ofthe-call condition, 
this condition can be verified in the recipient process. 

Field 6: Controls 

Remain the same. 

Steps for Enabling Payment by an advertiser 

Remain the same. 
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2,21b The Recipient Process in which SPQ Uses an IVR Switch 



Here we recap the steps of the core recipient process, adding matter where necessary to 
describing how the process is implemented for an IVR Switch embodiment. 

1. Register the recipient's identity. 

The exact method for identifying Reece depends upon the implementation. 

An IVR system can identify a recipient by a personal identification number (PIN) or an 
equivalent (such as a voiceprint). In certain cases, the recipient's number, captured 
through automatic number identification, may serve as a recipient ID. We will use the 
term PIN to represent a variety of methods for identifying and authenticating Reece. 

One goal for the operation of SPQ is to link a PIN with Reece's legal identity, so that he 
can be paid, and so that he cannot use multiple PIN's. Therefore, SPQ can require that 
Reece pre-register his legal identity and PIN at an SPQ website that lets Reece choose a 
PIN which SPQ then uploads to the IVR system. The IVR system stores the PIN in a list 
of authorized PIN's. 

An alternative is to enable Reece to register his legal ID through the IVR system, if it is 
his first time using SPQ. SPQ can let him choose a PIN as if he was using a website. The 
IVR system can enable him to enter his full name and address and unique identifying 
data. A minimal amount of data may be necessary. For example, the IVR interface may 
enable Reece to enter just his social security number. His PIN can then be associated with 
this data so that if he wins a payoff, his PIN can be associated with a unique, legal ID. 



72 



Of course, another alternative for assigning a PIN is to enable Reece to call a human 
operator who enters Reece's ID data into SPQ and assigns Reece his PIN. 
Yet another alternative is to not associate a PIN with legal ID data, such as a social 
security number or a fall name. It is possible to enable Reece to make up his own PIN 
and enter it via the IVR interface. The reason to use this method of identifying Reece is 
user-friendliness; Reece has to enter less data. This method is vulnerable to cheating in 
that Reece may register multiple identities. Still, it may be feasible to use such a method 
if SPQ includes other cheat detection processes, such as tests for detecting users who win 
an abnormal number of times. Therefore, just a PIN, determined by Reece, may suffice to 
identify Reece to the system. 



2. Find the offer, 

Reece enters the lookup code for Addy 's EVQ offer. We assume that the lookup code is 
Addy's phone number. The IVR interface registers the number and sends it to the switch. 

The switch checks to see if the phone number is on the list of authorized phone numbers. 
If not, the call is canceled. 

If the lookup code is recognized, the IVR interface registers the number and sends 
it to the switch to connect the call. 

3. Connect the recipient to the advertiser's advertising. 

The switch transmits the call between Reece ? s and Addy's numbers. 
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4. Register duration of the call. 

The switch registers the time/date and duration of the call. This data enables SPQ to 
verify that Reece has paid enough attention to qualify for the EV payment Addy has 
offered and enables toll charges to be applied. 

5. Send data to SPQ database. 

The IVR system and switch send the following data to the SPQ central database (where 
the rest of the recipient process is executed): 

a. Reece' s PIN, 

b. the lookup code (which we assume is Addy's phone number) 

c. the duration of his call, 

d. the time/date of the call. 

(Note: if the IVR is also used to enter Reece ? s legal identity and assign a PIN, then the 
IVR system would also send this data to the SPQ central database.) 

6. Possibly, register toll charges to the advertiser. 

If SPQ routes calls such that there is a toll charge, SPQ can also assess a charge to be 
paid (in most cases) by Addy based on the duration of the call. The charge is registered to 
Addy's account, which is identified by her phone number. 
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7. Verify qualified recipient conditions, in particular, that attention is paid. 

We assume that Reece must spend a threshold amount of time on the call to Addy's 
number in order to collect his EV payment. Addy may set the threshold as part of the 
terms of her EVQ offer, or the threshold may be standard. Thus, SPQ checks if the 
duration of the call is greater than the threshold. If it is not, SPQ does not register an 
acceptance. 

If Addy sets a custom threshold then SPQ must identify the offer and compare the 
duration of Reece 's call with her custom threshold. SPQ can identify her offer by the 
lookup code. 

Another Q-recipient condition, discussed above, is that Reece must call during a certain 
period in the day, e.g., from 9am-5pm. Thus, if this condition applies SPQ can check 
whether Reece has met it as well. If he has not, SPQ does not register an acceptance. 

8. If enough attention is paid, register an acceptance. 

If the duration of the call is greater than the threshold required, SPQ registers the 
acceptance of Addy's offer in an acceptance record. 

9. Apply the rule in effect regarding multiple acceptances. 

Remains the same. 

10. Execute the EV payment bet specified in the EVQ offer. 

Remains the same. 
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11. Record the results of the EV payment bet 

Remains the same. 

12. Inform the winning acceptor that he has won. 

Since Reece accesses SPQ via a voice interface, one way that SPQ can enable Reece to 
find out whether he has won the EVPM bet is to enable him to call the IVR interface, 
enter his PIN and, select a menu option for checking results. The IVR system can then 
connect with the SPQ central database and report to him if he has any "wins" for any 
EVQ offers he has accepted. Alternatively, SPQ can include a visual web interface that 
enables him to do the same thing — i.e., enter his PIN (user ID and password) and select a 
command for checking the results of his EVPM bets— of his acceptances of the EVQ 
offers, that is. 

13. Receive and register claim. 

Remains the same. 

14. Pass the claim to the inspector process. 

Remains the same. 
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Payment Steps in the Recipient Process 

Remain the same except for the addition, depending on the implementation, of assessing 
toll charges to advertisers. Where Reece accesses Addy by phone through the SPQ 
switch, toll charges will usually apply. If so, these charges need to be paid by someone. 
There are various ways to assess these charges to users. One way is to assess the charge 
to Addy. If so, SPQ will need to assess the charge as part of the recipient process, as 
discussed above. 

2.21c The Inspector Process in which SPQ Uses an IVR Switch 

Remains the same. 

2.21d Payment Processes in which SPQ Uses an IVR Switch 

The possible processes for transacting EV payments remain the same. Steps that may be 
added involve registering toll call charges, as discussed above. 



2.21e Producing Advertiser Reports 

Remains the same. 
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Claims 



I claim: 



1. an online database method and system for paying qualified recipients for their 
attention to messages; said method and system comprised of four core processes: 
an advertiser process, a recipient process, an inspector process, and a payment 
process; 

in said advertiser process, the system performs the following steps: 

a. registers an advertiser's identity, 

b. stores an offer by the advertiser, said offer including the following data: 

1 . a set of offer conditions, 

2. an EV payment and a payoff, 

in said recipient process, the system performs the following steps: 

a. registers a recipient's identity, 

b. finds an offer in response to the recipient's input, 

c. registers acceptance of the offer, 

d. executes an EV payment bet determined by the offer (selects a random number 
from a range dictated by the EV payment and the payoff), 

e. if the acceptor has won the bet: 

1 . informs him that he has won, 

2. receives and registers the acceptor's claim to be paid the payoff, 

3. passes the claim to the inspector process; 
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in said inspector process, the system performs the following steps: 

a. authenticates an inspector, 

b. retrieves a claim record, which includes the following data elements: the offer 
data, the recipient ID data, the acceptance data and, the claim data, 

c. presents an inspection report form, which includes fields for the following 
information: 

1) the name of the inspector, 2) the claim locator number, identifying the 
claim, 3) the decision, stating whether the claim is approved or rejected, 4) 
the explanation, stating why the claim is rejected, if it is rejected, 

d. when the inspector enters a decision, SPQ stores and timestamps the inspection 
report and associates the report with the offer data and acceptance data for the 
recipient, 

el. if the claim is rejected, the system notifies the recipient telling him of the 
rejection and, in the notice, includes the explanation stored in the explanation field 
of the inspection form, 

e2. if the claim is approved, the system passes the result to the payment process, 

in said payment process, the system performs the following steps: 

a. registers that the recipient is owed the payoff amount stated in the offer, 

b. notifies the recipient telling him he has won and is owed the payoff, 

c. notifies the advertiser that she owes the recipient the payoff. 
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Abstract 



A method and system is disclosed for enabling advertisers to pay only qualified people 
for receiving messages. The system presents online forms and a database that enable 
advertisers to specify qualifications, post payment offers, and transact payments. It also 
presents forms, or their voice equivalents, that enable recipients to find and accept the 
payment offers. The system can also enable recipients to be exposed to the messages. The 
system utilizes the EV payment method to efficiently pay a recipient and efficiently 
verify her qualifications. In this method, a recipient is paid an expected payment. The 
recipient collects an actual payoff only upon winning an EV payment bet and upon 
passing an inspection process to verify her qualifications. A losing recipient is not owed a 
payoff and does not have her qualifications inspected. In other words, a recipient's 
qualifications are verified through random audit where she is selected only if she wins an 
EV payment bet. Thus, the system executes EV payment bets and incorporates an 
inspection process to verify the qualifications of recipients who win the bets, and 
authorize payment to qualified winners. 
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